There exist commercial endeavors in which a plurality of computer application programs share a set of entities or subjects which are common to the application programs. For example, in the field of medicine, multiple different application programs may be used to store and manage different types of a data about the same patient. One application program may be used to store and manage clinical information about the patient, such as the patient's medical history, another application program may store and manage financial information about the patient, such as billing and insurance coverage information, while another application program may be used to store scheduling information, such as the date and time of the patient's scheduled future visits.
As another example, in the field of law, multiple different application programs may be used to store and manage information about the same client or case. A docketing application program may be used to store and manage information about upcoming deadlines and tasks to be performed with respect to the client or case, a billing application program may be used to store and manage information regarding the amount of attorney time spent on that client or case and the amounts charged to a particular client or for a particular case, and a document management application program may be used to store and manage documents created for a particular client or case.
Although a medical patient or a legal client or case are illustrative examples of entities or subjects that may be common to multiple different application programs, there are many other entities or subjects about which multiple different application programs may store different information. For example, the identity of a user of multiple different application programs is an example of a subject that is common to multiple application programs.
Data which describes a given entity or subject, and which is used commonly by a plurality of applications, is referred to herein as a “context” defined by that subject, and may be shared by two or more applications.
To access information about a particular entity or subject (e.g., a particular patient or legal case) from multiple different application programs, a user typically must individually sign in to each application program, and enter information into each application program that identifies the particular entity in which the user is interested. The desirability of managing context so that a user need not individually sign in to multiple different application programs and repeatedly enter the data describing the subject of interest into each of these application programs has been recognized. Examples of these techniques include single sign on (SSO) systems (i.e., wherein a user logs in to a single network-based resource and is automatically given access to other authorized network-based resources). As another example, a standard for context management, known as the Health Level 7 (HL7) context management specification, was published in 1999 by the Clinical Context Object Workgroup (CCOW). The CCOW standard defines a context management architecture (CMA) and processes for managing information describing a subject across a range of clinical and other healthcare-related applications. Examples of subjects that may define contexts shared by multiple different applications include a patient, a patient encounter, clinical provider, observation, insurer, and other subjects or entities.
Some of the application programs that may share context may be programs that are installed on the user's computer, some of the application programs may be web-based application programs that are hosted on a web server (which may be either inside or outside of the user's corporate network) and are accessed via web browser on the user's computer, and some of the application programs may be application programs hosted on a remote application server (e.g., a Citrix MetaFrame server, a Windows Terminal Server, or the like) that are emulated on the user's computer using an emulation client.
As mentioned above, a number of different techniques have been developed to enable two or more application programs to share context, such that a user need not individually sign in to each application program and/or need not separately enter information into each application program identifying a subject or entity of interest. For example, some of these techniques are designed to enable a user to enter sign on information only one time and, as a result, automatically be signed into multiple different application programs. Other of these techniques are designed to enable a user to enter or change context information in one of multiple different application programs and have each of the other application programs automatically change their context in the same way, without the user having to enter the context in each of those application programs. As an example in the medical field, upon detecting a user bringing up information about a patient in a clinical records application program (e.g., by entering information identifying the patient of interest into the application program), context sharing techniques may automatically change the context of the billing application program and the appointment scheduling application to the context defined by that particular patient.
One of these prior art techniques for context management is referred to herein as the “context-conforming application” technique. As this name implies, each application program is built or modified to conform to a context sharing technique that enables it to communicate with a central context manager, provide its context changes to the central manager, and receive context change updates in other application programs from the context manager.
As mentioned above, the CCOW standard is a known standard for context management. Among other features, the CCOW standard defines interfaces for inter-process communication, including communication between applications and a software-based module which coordinates the modification of data across applications (the “context manager”). One embodiment of a context manager is described in commonly-assigned U.S. patent application Ser. No. 09/545,396, which is incorporated herein by reference in its entirety.
The interfaces (“technology mappings”) defined by CCOW provide for communication between the context manager and various “styles” of applications, including those which follow the Microsoft Common Object Model (COM) and Hypertext Transport Protocol (HTTP) conventions, among others. For example, for a COM-based application, the CCOW standard specifies COM interfaces which allow the COM-based application to exchange data and parameters with the context manager when using a CCOW compliant context management system. The interfaces may be programmed to process COM-based data and parameters provided by the context manager and context participant applications to support the context management functions.
FIG. 1 depicts an exemplary context management system, in which a context manager 230 manages context for two context participant applications 210 and 220. Applications 210 and 220 may execute on the same or separate computers, and the computer(s) may be the same or separate from a computer on which context manager 230 executes. Communication between the processes may be enabled via any of numerous combinations of protocols and physical communications devices or components. For example, when the applications 210, 220 and/or the context manager 230 execute on the different computers interconnected by a network (e.g., a local area network), the TCP/IP protocol may be employed.
According to the CCOW standard, communication between the applications in a context and the context manager is facilitated through the use of context participant (CP) interfaces for the applications and a set of context manager (CM) interfaces for the context manager. Each of the CP and CM interfaces may comprise any of numerous suitable components for enabling inter-process communication. For example, each of the CP and CM interfaces is integrated in an associated application and provides a “plug” which enables communication with the application (e.g., CP interfaces 217, 227 may be implemented within applications 210, 220 respectively, and CM interface 235 may be implemented in an application program executing on the computer on which the context manager 230 executes). In the illustrative system of FIG. 1, the applications 210, 220 have CP interfaces 217, 227, respectively, associated with them.
Context participant (CP) interfaces 217 and 227, respectively, receive communications from context manager 230 on behalf of applications 210, 220. Applications 210, 220 may receive communications from the context manager 230 in a format and style commensurate with the CCOW standard (e.g., as COM messages or HTTP encoded messages over TCP/IP). In the embodiment shown, the communications pass through code portions 214 and 224 associated with the applications. CP interfaces 217, 227 may alternatively be incorporated directly into applications 210, 220 as described above, and directly pass communications thereto.
Context manager (CM) interface 235 receives communications from applications 210 and 220 and forwards those communications to the context manager 230.
As mentioned above, each of applications 210 and 220 includes a series of programmed routines integrated with the respective application code to perform context management support functions as defined by the CCOW standard. For example, applications 210 and 220 include code portions enabling communication with the context manager. Specifically, within application 210, code portion 212 defines messages sent to the CM interface 235, and code portion 214 implements the CP interface 217. Similarly, application 220 includes code portions 222 and 224 that, respectively, perform the same functions as code portions 212 and 214.
When a user of one of the applications (e.g., application 210) desires to switch the context by changing the data for a subject (e.g., switching from one patient to another), the application sends a request to the context manager 230 (via CM interface 235). The requesting application is referred to as an “instigator” of the requested change in the context.
When the context manager receives a request to change a subject of the context, context manager 230 surveys the other applications in the context (e.g., application 220), to determine whether the switch is acceptable to them. The context manager 230 performs the survey by sending a request to the other applications (e.g., application 220) via their associated CP interfaces. The other applications in the context may determine whether the subject change is acceptable or conditionally acceptable. While rules defining the acceptability of a subject change may be customized for specific applications and contexts, an example of a situation where a requested change may be conditionally acceptable is if data relating to the existing subject has not yet been written to permanent memory on the computer on which the application executes. In this example, the other application may respond to the survey by alerting the instigator that the data could be lost if a change proceeded. The surveyed applications respond to the survey by transmitting messages back to the context manager 230 describing their reactions to the requested change.
According to the CCOW standard, the context manager 230 communicates the results of the survey to the instigator application, and a user thereof examines the results and determines how to proceed. There are a range of options that the user can select, including canceling the requested change, executing the requested change, or removing the instigator application from the shared context. Any of these options can be selected by the user irrespective of the results of the survey. For example, if one or more of the surveyed applications indicates that the requested change is unacceptable to it, the instigator application may nevertheless force the context change, or alternatively, may simply remove itself from the shared context so that the instigator application can implement whatever changes it desires without impacting the other applications in the context. After the user decides how to proceed with the requested change, a call is made by the instigator application to the context manager 230 informing the context manager of the change decision. The context manager then makes one or more calls to publish the change decision by notifying the other applications in the context of the decision.
The above-discussed techniques rely upon context-conforming (also referred to as context-enabled) applications that have the capability to perform the above-described operations to enable their participation in sharing context. A technique referred to as “bridging” has been used for applications that do not conform to the CCOW standard. In this technique, the CM and CP interfaces are custom coded to be able to send data to and receive data from an application that is not context-enabled. Thus, these CM and CP interfaces may serve as a “bridge” that manipulates the application (e.g., by simulating mouse clicks and other user input). The bridging technique relies on software installed on the client machine to manipulate the application to change context or to notify the context manager when a change in an application's context is detected. In many cases, the software that is installed on the client is an interpreter that interprets executes a bridge script. Thus, the bridge may be thought of as a script that is executed by an engine or interpreter that is installed on the client. In some cases, rather than being implemented as a script, a bridge is implemented as hard-coded software that executes on the client. As used herein, “installed software” refers to non-transient executable software code that is stored in non-volatile memory within the client computer. One example of the above-discussed bridging technique is described in detail in pending U.S. patent application Ser. No. 10/632,673, which is hereby incorporated by reference in its entirety.
FIG. 2 is a diagram of an illustrative system in that provides context-sharing among a plurality of different application programs. In the illustrative system of FIG. 2, a desktop 300 (which may be executed on a single computer) executes three basic types of applications i.e., a locally installed and executing application (e.g., a COM-based application) 310, a browser 330 for a web-based application executing on a web server 500, and an emulation client 340 (e.g., a Citrix Independent Computing Architecture (ICA) client) emulating an application executing on a remote application server (i.e., a Citrix MetaFrame server) 600. Desktop 300 also includes a COM adapter 320 to facilitate communication between applications that employ different communication protocols (e.g., application 310 which uses COM-based standards for communication and application 530 on web server 500 that uses web-based protocols). In the embodiment shown, COM adapter 320 translates COM-based communication from application 310 to HTTP-based communication, and translates HTTP-based communication to COM-based communication for receipt by application 310.
Browser 330 communicates with a web server 500 via a network 700. Web server 500 executes a web-based context participant application 530. The illustrated desktop 300 also executes a emulation client 340, which is in communication with a remote application server 600 to initiate a session 610 within which one or more context participant applications may execute.
Context server 400 executes multiple context manager sessions 410A-C. In the example depicted in FIG. 2, context manager session 410A manages context for all the applications represented, including COM-based application 310, web-based application 530, and the remote application 615. To communicate with COM-based application 310, context manager session 410A transmits messages to COM adapter 320 via CP interface 375, and receives messages from COM adapter 320 via CM interface 420. To communicate with web application 530, context manager session 410A transmits messages to web server 500 via CP interface 510 and receives messages from web server 500 via CM interface 420. Finally, to communicate with the remote application 615, context manager session 410A transmits messages to COM adapter 617 executing on remote application server 600 via CP interface 640, and receives messages from COM adapter 617 via CM interface 420.
When a web application participates in a context, it is the application (e.g., application 530 in FIG. 2) executing on the web server that is the context participant, rather than the browser. Typically, when a change to the context is executed, the context manager publishes the change decision to the applications in the context. However, in the case of a web application, when the change in context occurs, the change takes place in the application 530 on the web server 500. However, because the web server does not initiate communication with the browser, the browser 330 may not be automatically made aware of the change, such that the representation of the state of the application 530 on the desktop 300 may be inaccurate. Thus, in the example of FIG. 2, a listener 335 is employed to assist in instructing the browser 330 to request updated information from its corresponding web server 500 when a change has been made to the web application 530 executing thereon. Listener 335 provides an interface (e.g., a CCOW interface) that the instigator application (i.e. the application that initiated the change in context) can contact to inform it that a change in the context has been made, so that the listener 335 can instruct the browser 330 to go back to the web server 500 for an update. When the context manager (e.g., session 410A) returns the survey information to the instigator application relating to a requested change, the context manager also provides a list of URLs (corresponding to the listeners for any web-based applications in the context) to the instigator application, instructing the instigator application to contact (or “touch”) those URLs to inform them that the context has been updated. When the instigator application is another application executing on the same desktop 300 as the browser 330 (e.g., the COM-based application 310), the instigator application can directly (e.g., through the COM adapter 320) contact the listener 335, as the URL for the listener 335 will be accessible from within the desktop.
In addition, the desktop 300 also includes a Context Management Registry (CMR) interface that the desktop can query to determine the identity (e.g., find the URL for) of a context manager to manage a context. In the embodiment of the invention illustrated in FIG. 2, the CMR interface 352 is implemented by a locator 350 provided on the desktop 300, with the CMR interface 352 being a plug into the locator 350. The CMR interface 352 can be queried by the COM-based application 310 (via the COM adapter 320) or the browser 330 to request the identity of the appropriate context manager (e.g., one of the context manager sessions 410A-C). When a context is initially being established (such that no context manager has been assigned to it), the locator 350 uses a URL provided in the CMR interface 352 to contact the context management server (e.g., context server 400) to initiate a context session. The communication from the locator 350 to the context server is directed to a location service (LS)(having a plug 421) that forms part of a context system 423 that manages the multiple context manager sessions 410A-C. Thus, this communication goes through a private interface, rather than through the CM interface 420 for any context manager session. When the locator 350 contacts the location service of the context system 423 to request a new context manager session, the context system 423 initiates a new context manager session 410A-C and returns to the locator 350 a URL that uniquely identifies the CM interface 420 for the new context manager session.
In the system of FIG. 2, a number of different software components are installed on the desktop 300. For example, a listener 375 for browser 330 is installed to notify the browser of changes in context, a COM adapter 330 is installed to notify listener 375 of changes in context, and a locator 350 is installed to enable the desktop to locate the context server 400. In addition, a context manager (CM) interface 420 is used to receive notifications of change in context from the web server and a context participant (CP) interface 510 is used to notify the context manager of changes. CM 420 and CP 510, or portions thereof that perform bridging, may also be installed on desktop 300. In addition, the application executing on the web server must be modified to conform to the CCOW standard.
As an alternative, rather than using a web-based application program that conforms to the CCOW standard, a bridging can be used. For example, a bridge may execute on desktop 300 to interact with the browser and communicate with the context manager.
Another known technique for providing single sign-on functionality for web-based application programs is referred to herein as “browser redirection.” While this technique provides SSO functionality, it does not enable ongoing context management/sharing, once a user is logged in. In this technique, when a web browser requests a sign on page from a web server to access a web-based application, the web server determines if the user is logged in. If the user is not logged in, the browser is redirected to a login server. The user provides his or her sign on information to the login server and, upon verifying that the sign on information is correct, provides a token (e.g., in the form of a unique identifier or encrypted data) on a redirect URL that is passed to the user's browser. The user's browser is then redirected to the web server hosting the web-based application that the user is attempting to access and the web server retrieves the token from the URL. The web server then uses the token to verify the user's identity (e.g., by communicating with the login server or a separate policy server), determine if the user is permitted to access the application hosted on the web server, and automatically sign the user into the application. Thus, once the token has been established, the user may access the web-based application or other web-based applications that accept the token without having to enter sign on information. This technique requires that the web-based application program be modified and additional software be installed on the web server to be able to recognize the token, verify the user's identity, and determine whether the user is permitted to access the application program.
Another known technique for providing single sign-on functionality for web-based application programs, without otherwise enabling the sharing of context between these application programs is referred to herein as “proxy sign on.” In this technique, an organization's domain name service (DNS) server is configured to map the domain names of web-based applications to a proxy server. The proxy server forwards requests from the user's browser to the web server hosting the application, receives the requested web page, and determines whether any of the requested web pages are login pages. If a login page is recognized, the proxy server, in a manner that is transparent to the user and the user's browser, determines if the user is already authenticated. If the user has not been authenticated then a separate login page is returned to the user's browser. The user enters his or her credentials in the login page and the proxy server validates the user's identity. Once the user has been authenticated, the proxy server retrieves the user's sign-in information for the original web page from a database or single sign-on server, and submits the sign-in information to the web server. Once the user is logged in, the proxy server simply passes requests from the browser to the web server and returns the responses from the web server to the browser and does not interact with the application.
This technique works with web-based application programs that allow login by simple submission of sign on information, but may be difficult to use with other application programs. That is, for example, some web-based application programs include code (e.g., JavaScript code) in a login page that must be run in the user's browser in order for the user to successfully sign in. Such code may, for example, apply a cryptographic hashing function to the user's password before it is returned to the web server. The proxy server would not be able to successfully sign in to such an application program because it merely provides the user's sign on information to the web server without executing the code that hashes the sign in information before it is submitted. Moreover, this technique presents additional challenges when the session between the web browser and the web server is encrypted (e.g., using transport layer security (TLS), secure sockets layer (SSL), or another encryption protocol). That is, when the web pages sent from the web server to the browser are encrypted, the proxy server may be unable to determine whether a web page is a login page and may be unable to submit the user's login information in encrypted form.